IBIS Macromodel Task Group Meeting date: 18 July 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to email his BIRD158.6 draft 1 comments to the ATM reflector. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Ambrish: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Walter's 3 proposed motions (from an email regarding BIRD190 & BIRD166): ******* Motion 1: Do you agree that a redriver channel with Tx1, Rx1, Tx2 and Rx2 being Init-Only models: 1. IBIS 6.1 Redriver Flow gives the wrong answer. 2. BIRD 166 gives the right answer. Motion 2: Do you agree that a redriver channel with Tx1, Rx1, Tx2 and Rx2 being Dual models: 1. IBIS 6.1 Redriver Flow may give the wrong time domain answer. 2. BIRD 166 gives the right answer Motion 3: Do you agree that a redriver channel with Tx1, Rx1, Tx2 and Rx2 being Dual models: 1. IBIS 6.1 Redriver Flow gives the wrong statistical answer. 2. BIRD 166 gives the right answer ******** - Arpad: I'm confused by these "motions" in the form of questions. - Are these just discussion proposals/questions? - Walter: The intent was to establish who believes these statements are true. - I believe IBIS 6.1 is wrong under these 3 circumstances, and BIRD 166 gets the correct results under these 3 circumstances. - I believe BIRD190 reinforces an incorrect flow. - If we go to the Open Forum and Ambrish defends BIRD 190, I will explain that it's a bad idea. - Bob R: I think it's fair to discuss each of the technical points without prejudice, to see if there is any common agreement. - Arpad: Okay, we will start with discussion here, and we can make any motions later if we need them. - Ambrish: BIRD166 affects statistical and time domain flows, correct? - Walter: Yes. - Ambrish: Do you agree that the 6.1 time domain flow is not broken if there is no optimization in Init()? - Walter: Yes, if all the models have GetWave() and there is no optimization in Init(). - Ambrish: That is the reason that we have the note (warning about optimizing in Init()) in the spec. - Fangyi: Regarding motion 2, number 2: When the redriver has non-linearities and internal noise your BIRD166 will artificially inflate them. - Walter: No, motion 2 says all models are Dual, so they all have GetWave(). - Fangyi: Then we need to add an additional motion for mixed Dual mode and Init Only models. - Walter: I think your counter argument (see ATM minutes and work archive May 9, 2017 for counter example) was specious. - In your example you treated the Rx2 as having a linear part and an additive DFE part. It's technically correct. However, if the input waveform has the correct amplitude, then you can treat the DFE as multiplicative not additive. It's a different way to do the deconvolution to get the equalization of the Rx2, as long as the amplitudes are reasonable. - Fangyi: That's not a valid issue. - Walter: That same issue occurs for the single channel case if the Rx is Init Only and the Tx has a GetWave(). - But we know those mixed mode cases can be problematic, and there may be other flows that handle them. - I want to concentrate on three basic cases I described (in the motions). - case 1: All Init Only models - Are statistical simulations correct with the current flow? - Arpad: With or without optimization in Init()? - Walter: There are two reasons it's wrong. - First, it's obviously incorrect if there's optimization in Rx2 Init(), because Rx2 doesn't get the upstream effects in its input IR. - IBIS 6.1 guarantees that the input IR to Rx2 will not be the complete IR (the upstream information will not be included), so the results will not be correct. - Second, even if there's no optimization in Rx2 Init(), if Rx2 has DFE then when you convolve the output of Rx2 Init() with the output of Rx1 Init() you end up scaling the linear and DFE portions of the Rx2 equalization. So you get the wrong answer with the current flow. - Time domain simulation when all the models are Init Only is broken for the same two reasons. - Arpad: If Rx1 had a DFE then even your BIRD166 would still have a problem? - Walter: We are talking about redrivers not retimers. DFE requires a CDR and other things a redriver won't have. - Ambrish: You would change the flow for this one-in-a-trillion case where all four models are Init() only and you want to do a time domain simulation? - Walter: If you use BIRD 166, and use the IR output of Rx2, then you will get the right answer for statistical or time domain flows. IBIS 6.1 will give you the wrong answer for both. - There are companies that only do Init() models. - Fangyi: The redriver simulation is all about non-linearities in the redriver device, otherwise we wouldn't have needed the redriver extensions to AMI. A redriver will have GetWave(), and most have two modes, a linear mode and a limiting mode. - Walter: Yes, statistical is not a complete solution if there are non-linearities. I'm not disagreeing. - There are problems with mixed Init Only, GetWave Only, Dual model simulations. - But we ought to get it right if all four of the models are Init Only. - Ambrish: Redriver is already a special case of AMI flow. - The spec. goes into great detail about a single Tx to Rx channel. - There are already exceptions and warnings in the spec. - You're modifying the flow for a special case. - Walter: In a simple channel Init Only flow, the Rx has all the upstream equalization. - With a redriver I'm simply saying the terminal Rx (Rx2) needs all of the equalization for everything upstream. - Ambrish: My problem is that you're taking a one-in-a-million case and trying to drive the conversation with it. - Fangyi: I agree with that. - Walter: The all dual model case is not as rare. - Walter: Why do you object to having Rx2 Init() get the right input IR if all the models have GetWave() anyway (all dual models)? - Ambrish: Because as the spec is written, the Rx2 IR does not matter at all if you have a GetWave(). - Fangyi: Also because if you have the combined IR you introduce more problems. - Ambrish: You're trying to circumvent the warning note in the spec. - Walter: No. The note in the spec is a valid note to all Rx model writers. - It says that the Rx model can't be assured that the IR it gets will be complete. Therefore, it can't always rely on automatic optimization and needs to provide an override mechanism. That is true in all cases. - What I'm trying to do is give the Rx2 Init() in a redriver simulation the best IR it can get. - IBIS 6.1 guarantees that Rx2 will not get the complete equalization it needs under any circumstances (because the redriver flow says you convolve with the output of Rx1 Init() after Rx2 Init() is called instead of before). - BIRD 166 corrects that. - Ambrish: The original warning says IR "may" not include all the effects. - The EDA tool could already do something different if it wanted to. - Arpad: I need to comment on that point. - We do say somewhere in the spec that these reference flows need not be implemented exactly, but that whatever method is implemented should generate identical results. - Here the spec clearly says to combine the output of Rx1 Init() with the output of Rx2 Init(). If a tool changes this order the results would be different and you're not spec compliant. - Walter: I had proposed adding a line to BIRD 190 that would have made it acceptable to me. - I wanted to add a line saying the EDA tool could choose to combine the upstream channel with the Input to Rx2. - Are you saying you now agree with that Ambrish? - Ambrish: I would like to add an additional discussion point to this list. - Do people think any optimization should happen in Init() or only GetWave()? - If the original intent of the specification was that optimization can happen in Init() then why would the note be there? - Walter: Going back 9 years ago, Kumar wanted to do optimization in the Tx so it could choose coefficients optimized for the channel to open the eye at the Rx input pad. - That's why the input to the Tx or Rx Init() is the channel IR itself. - From day one it was expected that the Init() functions would optimize themselves. - Ambrish: That was for getting the tap weights in the Tx if you didn't want to bother with a GetWave() for the Tx. - If you have a GetWave() in the Tx then you can ignore the Init(). - If you've done the hard work of implementing a GetWave(), why would you want to use the Init()? - Walter: Question: How can Tx GetWave() optimize itself? - Ambrish: Tx GetWave() just implements the tap coefficients. - Walter: How does GetWave() get the tap coefficients? - It gets them from the Init(), either as user input or as values the Init() selected based on the IR to optimize the channel and open the eye at the Rx input. - How could Tx GetWave() optimize itself dynamically (its input waveform is just the "digital" stimulus waveform)? It can't. - Ambrish: Not true, you can have pattern dependent GetWave() that optimizes in the Tx. - Walter: I think we are not going to get an agreement on this. - I think we have documented these points of disagreement. - If people want to pursue BIRD190 in the OF, I will present this discussion and argue against it. - Ambrish: BIRD190 is just a clarification. - Walter: By adding BIRD190 you are reaffirming that we guarantee Rx2 won't have the complete IR. - Radek: I think BIRD190 would be perfectly fine if we change the word "note" to "warning." That may be all we need. - Ambrish: I'm fine with that. - Walter: If BIRD190 just said, "warning Rx2 Init() does not necessarily get the full IR," that would be OK. - But I don't want to reaffirm the problem in IBIS 6.1 with Rx2 Init(). - I'm okay with doing nothing at all if we can't come to agreement. - Arpad: A few meetings back we had a straw poll. - The results of that were that we would do neither BIRD166 or BIRD190. - We were going to consider further developing Fangyi's proposal. - Where do we stand on that? - Ambrish: I think that poll was flawed because BIRD190 was considered to apply to statistical flow as well, and I don't think it does. - We have major disagreements because Walter says the current spec doesn't work. - We can't guarantee all of the special cases will work. - Walter: BIRD190 is tabled in the Open Forum. I guess that will continue. - Ambrish: I will have a motion on BIRD190 for this meeting next week. BIRD158.6: - Radek: I sent out a response to Arpad's comments just before this meeting. - I'm not available for next week's meeting, but we can work on this via email and discuss it in the following week's meeting. - Arpad: I encourage everyone to review that email discussion. BIRD191: - Bob R.: I'm thinking of drafting a BIRD191.1. - The gist of it is a one sentence statement that "Die" shall be considered the buffer location. - Walter/Arpad: Send it to the ATM reflector and we will review it. - Bob R.: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 25 July 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives